perm filename SCU[P,JRA]1 blob sn#441450 filedate 1979-05-17 generic text, type C, neo UTF8
COMMENT āŠ—   VALID 00005 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002
C00005 00003
C00011 00004
C00013 00005
C00017 ENDMK
CāŠ—;

Outline of General Philosophy

Both educational and  industrial computer systems  projects suffer from  a
common malady:  inadequately  prepared programming  staffs.  This  results
from a  general misconception  concerning the  difficulty of  programming;
frequently one hears statements expressing the sentiment that "anyone  can
program."  Of course that  opinion is as accurate  as "anyone can write  a
poem."  Our argument  therefore involves  a perspective  on improving  the
quality of programming and the programming process, rather than approaches
to the mechanics  of learning the  syntax of a  particular language.   The
former is an important facet of a university education in modern  computer
science; the latter is not.

In a  field  with  growth  as  rapid as  that  of  computer  technology  a
university must be prepared  to educate students  in fundamental ideas  as
well as expose them to  current technology; for otherwise their  education
will be obsolete even before they graduate. This is well understood in the
hardware field; this area has a substantial background to draw from in the
physical sciences. However, the situation is not so well developed in  the
software domain. There  is no  historical precedent  for handling  problems
with the  complexity  of  modern computer  systems.   Current  efforts  in
"programming methodology" represent initial attempts to come to grips with
these  problems.   Unfortunately  many  of  the  approaches  involve  only
syntactic or superficial solutions, restricting the expressibility of  the
programming  languages  (and   therefore  the   programmer)  rather   than
addressing the problem  as a semantic  one requiring an  education in  the
ways of thinking about  complexity coupled with  a collection of  computer
tools which expands the programmer's expressibility.



What a University Computing Facility Should Represent

A university program  which involves  technology must  be a  model of  how
things should  be done,  not how  things are  done. Alas,  most  computing
centers fail this miserably.  As a  result, students are still trained  to
think and act about computing in fashions which were current twenty  years
ago --batch  processing,  card  input,  paper output.   This  is  a  major
difficulty: the  complexity  and  expectations of  software  products  has
increased phenomenally. Unfortunately, the way we deal with computers  has
changed very slightly; batch processing is faster, and we may use a "glass
teletype" to prepare  the input and  receive the output,  but the  general
paradigm still holds.  Until very recently, such behavior could be excused
on financial grounds; only very  few research establishments could  afford
to develop and support quality tools, and only then for a select number of
individuals. Technology  has  changed that;  even  contemporary  eight-bit
microprocessors can  support reasonably  robust programming  environments.
That is the  lesson in the  success of personal  computing and BASIC.   An
"inelegant"  language  in  an  attractive  package  has  done  wonders  in
de-mystifing computers.

The university role  in computing  can take several  further lessons  from
this experience. It is the quality  of the tools which make the  computing
environment either friendly  or hostile. Most  computing environments  are
quite  hostile;  this  makes  for  slow,  unsatisfactory  development;  it
constrains the programming process to  the point that creativity  suffers.
That is hardly an atmosphere in which we should expect to develop our best
software people. Therefore the center should be exemplar in the quality of
the general programming environment.  This includes programming tools like
general purpose display editors which allow text manipulation superior  to
that currently available with hardcopy.  Such editors have been in  common
use since 1965 at the  Stanford Artificial Intelligence Laboratory;  their
use has  spread through  the AI  community.  What  is new  is that  recent
technology has made this display  philosophy economically viable. What  is
needed is  the realization  that  such tools  exist  and can  improve  the
programming process.

Further, the center should develop and support a student environment which
reinforces the methodological concepts  which aid in creating,  modifying,
and maintaining  large  complex software  projects.   Again, many  of  the
experiences of the AI community are applicable here. The complexity of  AI
programs is rivaled by  few other software efforts;  the success of  these
programs is a direct result of the quality of their tools. The environment
of  a  conventional  personal  computer   pales  in  comparison  to   that
experienced by an  AI researcher. Such  environments are still  expensive,
yet, in a few years, technology will again allow economical development of
such systems.   (The results  of  Xerox's Palo  Alto Research  Center  are
beginning to bear this out.)

Therefore the university role must be to expose the students to this "high
technology software",  while giving  them the  intellectual education  and
training to apply  it wisely. It  is this area  which is most  overlooked:
high quality tools cannot be used effectively by untrained individuals.  A
programming methodology  which develops  a sense  of maturity  within  the
individual is an integral part of  the program. The current trends  toward
language-enforced discipline are  only short-term solutions  which may  do
more harm than good.

Conclusions

Santa Clara University is in an enviable  position. It is in the heart  of
the most technologically advanced part of the world. Its computer  science
program can therefore both draw from the richest well of talent and at the
same time  influence  the future  course  of software  development.   This
valley is reknowned for its  hardware development; its software, and  that
of the  industry in  general, is  a wasteland.   An agressive  program  is
needed; it will do well.

In this brief  outline I have  discussed a general  philosophical view  of
computing and university education. I have not touched on the relationship
between education  and a  research  facility, though  I  feel that  it  is
important to commingle the facilities  and the personnel. Further, I  have
not delved into  a detailed plan  that  would support  such a venture.  If
there is  interest in  discussing  details I  would  be quite  pleased  to
describe a concrete proposal.  You may contact me at the addresses below.


				Sincerely yours,


				John R. Allen
				18215 Bayview Dr.
				Los GAtos, Ca 95930
				(408)353-2227

				Signetics Corp.
				811 E. Arques Ave. MS.38
				Sunnyvale, Ca 94086
				(408)739-7700 x6304

Roger:

I am sorry to be so impatient  about our arrangements, but time IS of  the
essence.  If I cannot feel  that I can complete  this project in a  timely
and professional fashion,  I will  drop it; a  date for  that decision  is
close at hand.

Following are some general questions  and points which should be  resolved
before we are to sign an agreement: (the order is totally random)

1. I assume that we will incur no liabilities due to a customer's use  (or
misuse) of the product. Our responsibilities are restricted to producing a
quality product and fixing any bugs which occur.

2. Will the name  of our partnership be  associated with the software  you
release?

3. Will the money be made available at the time the agreement is signed?

4. How soon after the signing will the machines be available?

5. Will  the  necessary software  be  included with  the  machines?   (for
example:   assembler,  C,  word  processor,  trace  package,  and  editors
(teco-like and display-oriented)?

6. Do  you have  a  conversion program  which  will take  Intel  formatted
floppies to your format?

7. Is there an extra RS-232 port available on the machines; if not, can we
get one included?  Similar question about a PROM burner.

8. What are  the dimensions  of the new  dazzler?  If  the dimensions  are
around 264x480 it could be quite useful (for both parties)

9. What kind of  assistance can we  get on the  production of the  manual?
Proof reading? copy-editing?

10. We must have some agreement about the maintenance of the hardware.  If
something malfunctions before  the software  delivery date,  we must  have
timely repair or replacement. Similarly some decisions must be made  about
hardware maintenance during our period of software maintenance.

One final question: what is your assessment of the LISP market? i.e.,  how
many copies do you expect to sell?  Probably other questions will come up,
but hopefully this list will cut down some of the iterations. The prospect
of developing  a small,  quality  LISP system  is exciting;  however  that
excitement is dampened as the end of September gets closer. A bad LISP is
worse than no LISP.